1. Field of the Invention
The present invention relates to a simulator operable to simulate, using software, behaviors of processors such as a DSP (Digital Signal Processor), and an art related thereto.
2. Description of the Related Art
The development of built-in software entails steps as discussed below. At an initial step, source codes are described in high-level language such as C/C++. In the source codes, descriptions that value performance (e.g., an amount to be processed, and an amount of resource consumption) are coded in assembler language.
At the next step, the coded software is executed on a simulator to debug the source codes. The simulator simulates target resources (a register and a memory) such as a DSP, and their behaviors.
The simulator is used during the debugging of the source codes. The simulator is run on a host processor such a personal computer (PC) and a work station (WS). The simulator is operable to stop the software in execution from running in timed sequence, to reference the various resources (the register and the memory) to see how they are, and to set a value to each of the various resources.
Patent Reference No. 1 (published Japanese Patent Application Laid-Open No. (HEI) 5-233317) discloses a simulator operable to display a name of a function after the execution of the software, in which the function has written data to a memory specified in advance by commands.
The following discusses the software simulator as taught by Patent Reference No. 1.
FIG. 33(a) is a flowchart illustrating the software simulator of Patent Reference No. 1. FIG. 33(b) is a region access table prepared by the above software simulator.
In FIG. 33(a), at step 3300, a command is entered. At step 3301, the command is analyzed.
When the analysis shows that the entered command is a region access command, then the region access command is processed at step 3303.
When it is determined at step 3303 that the entered command is a setacc-command, then the region access table 3308 as illustrated in FIG. 33(b) is drawn up in accordance with command-specified address information.
When it is determined at step 3303 that the entered command is a getacc-command, not the setacc-command, then the name of a function consistent with the command-specified address information is displayed in the region access table 3308.
At step 3304, a determination is made as to whether or not the entered command is an instruction-executing command. When the determination in step 3304 answers “NO”, then the routine is returned to step 3300.
When the answer to the determination in step 3304 is “YES”, then single instructions are executed at step 3305. At step 3306, a determination is made as to whether or not data has been written to a region specified by the setacc-command.
It is determined at step 3306 whether or not the instructions executed at the previous step are memory access instructions. When the determination in step 3306 answers “NO”, then the routine is terminated.
When it is determined at step 3306 that the executed instructions are the memory access instruction, and further when address information contained in the region access table 3308 includes a write destination to which the data was written, then the name of the function including the executive instructions is placed into the region access table 3308.
At step 3307, a determination is made as to whether or not the execution of the instructions is completed. When the determination in step 3307 answers “NO” and therefore the execution of the instructions must be continued, then the routine is advanced to step 3305. When the answer to the determination in step 3307 is “YES”, then the routine is returned to step 3300.
In this way, the simulator as disclosed by Patent Reference No. 1 is designed to display the name of the function after the execution of the software, in which the function has written data to the memory specified by commands in advance.
The prior art simulators are, however, incapable of checking up on the occurrence of access (read and write) to the resources (the register and memory) beyond the range intended by software developers, and of checking data obtained during the access (read and write) to the resources (the register and memory) to determine whether or not the data has a value intended by the software developers. When unintended access or data drives the software to malfunction, then the software developers must repeat the steps of executing the software, stopping the software, and referencing the resources to see how the resources are, in order to pinpoint problems in the software. As a result, software development is performed with considerably reduced efficiency.
The prior art simulators are operable to check, for each of the executive instructions during simulation, whether or not certain instructions have been executed, and to record such a history. However, the prior art simulators have another problem with conditioned instructions that force the executive instructions to change a course of action in dependence upon a register value. For example, the conditioned instructions branch off each step to a specified address when the register has the value of “0”. More specifically, the prior art simulators are incapable of checking conditions under which the conditioned instructions have been executed. As a result, there is no way to ascertain whether or not the developed software is run in all respects in accordance with the intent of the software developers.
The software simulator as disclosed in Patent Reference No. 1 is capable of checking up on neither access to the register nor read from the memory. For writing data to the memory, the software simulator is merely able to display histories on the function name after the execution of the software, but is not able to pinpoint problems in the write.